Create a mock ArgumentsHost as a plain object cast to the interface and call catch() directly — no HTTP server required. Use Test.createTestingModule() to resolve the filter with its injected dependencies. Assert that res.status() and res.json() were called with the expected arguments.
Call catch() directly — no need to spin up an HTTP server for unit tests.
Create the mock host as a plain object cast to ArgumentsHost using as unknown as ArgumentsHost.
Mock switchToHttp() to return mock getResponse() and getRequest() functions.
Use jest.fn().mockReturnValue() chaining to simulate res.status(n).json(body) fluent API.
Test both HttpException branches and non-HttpException (unexpected error) branches separately.
Suppose you have a simple NestJS exception filter that catches NotFoundException and returns a 404 response. How would you write a unit test to verify that the filter sets the correct status code and message?
If you run a test for your exception filter and the response body is undefined, what could be missing in your test setup?
You added a custom exception filter that logs errors to an external service. During a unit test, the test hangs. What might be causing the hang and how would you adjust the test?
When refactoring a filter to use the NestJS ArgumentsHost, a teammate reports that the unit test now fails with a type error. How would you debug and fix the test?
In a large microservice, multiple exception filters are applied globally and per-controller. How would you structure your unit tests to ensure each filter’s behavior is isolated and doesn’t interfere with others, especially regarding shared mocks?
Your team wants to achieve high test coverage for exception handling without slowing CI pipelines. What strategies would you use to keep the unit tests for filters fast and reliable at scale?
Your organization is migrating from a monolith to a NestJS-based microservice architecture, and you need a consistent testing strategy for exception filters across many services. How would you design a shared testing library or pattern that balances flexibility and maintainability?
There’s a proposal to replace NestJS exception filters with a centralized error handling middleware to simplify testing. What are the trade‑offs of that approach, and how would you convince stakeholders based on testing considerations?